The Internet Key Exchange Protocol version 2 (Internet Key Exchange Protocol Version 2, abbreviated as IKEv2) is used to authenticate a security association (Security Association, abbreviated as SA) and negotiate keys on a virtual private network (Virtual Private Network, abbreviated as VPN) and is related information required by both communication parties on the VPN to negotiate Internet Protocol security (IP Security, abbreviated as IPSec) communications, for example, encryption algorithm, session key, authentication of both communication parties, and the like.
The IKEv2 negotiation is divided into initial exchange, auth exchange, create child exchange, and informational exchange. Message headers of each IKEv2 message include a message id field (message identity), where the message id field is used to identify the sequence number of a message.
Generally, both communication parties store two message ids: a send_message_id (abbreviated as send_msgid) used when a request message is initiated, and a recv_message_id (abbreviated as recv_msgid) that is the message id of a message that expects to be received. After a communication originator sends a request (request) message for a message_id and receives a response (response) message of this request message, the send_message_id in the communication originator increases by 1. The recv_message_id increases by 1 each time when any communication side receives a request message.
In an IPSec host standby scenario, an active device (active member) is a device that is communicating with a peer device (peer device), and a standby device (standby member) is a backup device of the active device. When a fault occurs on a communication link between the active device and the peer device, the standby device is switched to a new active device to continue communication with the peer device.
If a fault occurs on the communication link between the active device and the peer device when the active device is performing an IKEv2 negotiation with the peer device, the standby device is switched to a new active device. Because the identity information in the original active device is not backed up into the standby device promptly, the message id in the standby device may be different from the message id in the active device. At this time, the communication with the peer device may be interrupted due to the wrong message id.
For example, during the IKEv2 negotiation, after the active device sends an msg1 to the peer device, the active device and the standby device are switched, and the updated information of the send_msgid of the active device is not backed up into the standby device promptly. In this way, the standby device is switched to a new active device, and the send_msgid is not updated. Therefore, the message_id of the new active device does not match the message_id of the peer device during the negotiation. As a result, services are interrupted for a long time.